home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000020_icon-group-sender _Mon Sep 14 08:24:11 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  7KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06348
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 14 Sep 1998 08:24:11 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA01625; Mon, 14 Sep 1998 08:23:43 -0700
  7. From: gep2@computek.net
  8. Date: Sat, 12 Sep 1998 05:39:34 -0500 (CDT)
  9. Message-Id: <199809121039.FAA15753@mail.cmpu.net>
  10. Mime-Version: 1.0
  11. Content-Type: text/plain
  12. Content-Transfer-Encoding: 7bit
  13. Subject: Re: Unicode support or support for non-Ascii based character
  14.     manipulation?
  15. To: icon-group@optima.CS.Arizona.EDU
  16. X-Mailer: SPRY Mail Version: 04.00.06.17
  17. Content-Transfer-Encoding: 7bit
  18. Content-Transfer-Encoding: 7bit
  19. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  20. Content-Transfer-Encoding: 7bit
  21. Status: RO
  22.  
  23. > ASCII is also NOT adequate for many purposes even in the United
  24. States.  
  25.  
  26. Of course.  Icon isn't the language of choice for writing device drivers, 
  27. either.  The point is not that it's not perfect FOR EVERYTHING, but that it's 
  28. damned useful (and reasonably efficient) just as it is.  If something has to be 
  29. built ON TOP OF IT, then the person who needs those higher-level function has 
  30. many of the tools needed to do that.  You shouldn't force EVERYBODY to use the 
  31. higher-level functions just because SOMEBODY, SOMEWHERE decides that they want 
  32. them.
  33.  
  34. > Almost every word processor has their own incompatible way of
  35. representing diacritical marks and characters that were omitted from
  36. ASCII.  
  37.  
  38. Sure.  And there are all kinds of other details which are not readily 
  39. represented by any simple character set customization, too (complex mathematical 
  40. formulas, for example).  I wouldn't insist on using TeX (or whatever) to produce 
  41. my clients' invoices just because somebody needed that level of functionality 
  42. for the particular stuff that THEY are doing.
  43.  
  44. > (By the way, did you know that there are other countries in
  45. the Western Hemisphere besides the United States?  And most of them
  46. don't speak English?)  
  47.  
  48. Don't be condescending.  
  49.  
  50. > I work in a library, and libraries found plain
  51. ASCII inadequate all the way back in the early 1960s, when the
  52. computer programmers were still bitching about people who wanted
  53. lowercase letters.  
  54.  
  55. It's already been pointed out in this thread that the 65536 unique characters 
  56. allowed in Unicode aren't even universally agreed as being "enough" and there 
  57. are already people jockeying to push for more.  Personally, ASCII works plenty 
  58. well enough that I am not eager to see (for example) my E-mail archives blossom 
  59. to twice the disk space they already take up.  I'm not eager to see Web pages 
  60. take twice as long to download than they need to.  One poster mentioned a 
  61. compression scheme to allow them to be smaller than 2x, but that comes at added 
  62. complexity (which isn't pretty either).
  63.  
  64. >> If other countries have more difficult (or huge) character sets,
  65. > that is (while a fact of life) simply an inherent disadvantage
  66. > of their culture (and note that I'm not intending that as a slam
  67. > or value judgement, it just IS the way it is), and I don't see a
  68. > terribly convincing argument why the other countries (without
  69. > that disadvantage) ought to pay the price too, just in order to
  70. > artificially level the playing field.
  71.  
  72. > Many of those non-Roman character sets are no more difficult than
  73. Roman.  
  74.  
  75. True enough, but supporting all of them simultanously is undeniably more 
  76. difficult and complex (for example, mixing left-to-right and right-to-left 
  77. languages on the same line is a major pain.  
  78.  
  79. So let's say for example that you're going to try to support English and Hebrew 
  80. within a single string.  Are you going to ask Icon's string scanning to scan the 
  81. resulting mess in the "correct" way (i.e. left to right through the English 
  82. part, then jumping to the right-end-beginning of the following Hebrew word, 
  83. continuing to the left, then jumping across the Hebrew word to continue with the 
  84. English word to its right?  And are you going to ask programmers of high-level 
  85. applications to design their programs so that these kinds of exceptions and 
  86. special cases for exotic character sets all work within their applications?  
  87. Frankly, I just don't think it's usually worth it.
  88.  
  89. Sure, some people need such things.  For them, there are special-purpose 
  90. multilanguage word processors (Multi-Lingual Scholar, Nota Bene, and numerous 
  91. others).  And I still think Icon is as good or better than most other languages 
  92. for writing applications that have to do weird stuff with character strings.  
  93. But I don't really want to have to have all that paraphenalia around and 
  94. imposing itself on me all the time.
  95.  
  96. > The United States is not an island.  Closing our eyes and pretending
  97. that rest of the world doesn't exist and doesn't buy our software
  98. would be a bad idea even if it was possible.
  99.  
  100. That's fine, but we're also large enough that we can (and probably should) allow 
  101. ourselves to benefit from the efficiency that our systems make possible (_where_ 
  102. possible!)   The companies I typically consult with certainly don't need Unicode 
  103. to produce their accounting reports, nor for their invoicing or communications 
  104. or other functions.  It would be ridiculous to build those kind of back-office 
  105. applications the same way (even using the same tools, probably) that one would 
  106. build a program that had to handle sanskrit or Chinese or something.
  107.  
  108. > If you're concerned about efficiency, maybe you should worry about all
  109. the gratuitous graphics.  
  110.  
  111. I talk about my attitude about such things at my Web site (see the FAQ).
  112.  
  113. > Over uncompressed ASCII, compressed Unicode
  114. uses little to no more disk or tape space.  Compressing and
  115. uncompressing strings adds some complexity, 
  116.  
  117. More than a little, I think.  Frankly, I don't think that (for the great 
  118. majority of users here) that added complexity comes with enough benefit to 
  119. justify the hassle.
  120.  
  121. > but you get some
  122. simplicity by not having to keep track of which character set you're
  123. in and switching back and forth between character sets within what is
  124. logically one string.
  125.  
  126. Character sets are not by themselves enough (as I discuss above regarding 
  127. character DIRECTION also changing within a string).  Once you decide to support 
  128. EVERYBODY's weird stuff in the basic system, you're starting down a very 
  129. slippery slope, with the probability that you're STILL not going to please 
  130. everybody... and that by trying, you end up pleasing NOBODY at all.
  131.  
  132. Gordon Peterson
  133. http://www.computek.net/public/gep2/
  134. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  135.  
  136.